Overview

This PR adds a command to control the status bar to run a few select animations on it. The animations available are expected to be the ones that the app may want to remotely trigger the robot server to run based on some design workflows.

The animation will NOT run if a protocol is currently running. This is mostly handled implicitly because the stateless commands can't run while a protocol is running, but we also want to block out the animations from running when a protocol is completed but not acknowledged (status bar is either green or red for success or failure). To accomplish this, the command checks if the current status bar state indicates that it is being controlled by the background Light Control Task.

Test Plan

Used the POST /commands endpoint to send setStatusBar commands.

• When the robot is idle, you can send any of the enumerated options and they'll animate the bar appropriately
• When the robot is in the middle of a run, the endpoint either gives an error code (if the run is actually running) or silently fails to run the command (if the run is waiting to be acknowledged). This is as expected.

Changelog

• added a StatusBarHandler class to be able to mock out status bar setting
• added StatusBarHandler to the protocol engine
• added a setStatusBar command to the protocol engine
• updated protocol engine json schema to add new command

Review requests

• Is this the correct way to have an enumerated string parameter for a command? I copied what the moveToMaintenancePosition command does.
• I regenerated the schema after these changes but did I miss anything for integrating the command?

Risk assessment

Pretty low as long as all the CI for the protocol engine keeps working.